GTPP Accounting Overview
GTPP Accounting Overview
 
 
This chapter provides an overview of GTPP accounting, GGSN Call Detail Records (G-CDRs), Enhanced GGSN Call Detail Records (eG-CDRs), PDN Gateway CDRs (PGW-CDRs), and Serving Gateway CDRs (SGW-CDRs) in the Cisco ASR 5000 Series Multimedia Core Platform.
 
 
Overview
This section provides information on GTPP interface between Charging Gateway Function (CGF) and Cisco Systems’ licensed products running on the ASR 5000 core platforms, such as Packet Data Network (PDN) Gateway (P-GW) and Serving Gateway (S-GW) in 3GPP2 evolved High Rate Packet Data (eHRPD) and Long Term Evolution-System Architecture Evolution (LTE-SAE) wireless data networks.
The Ga is the reference point from Charging Data Function (CDF) to the CGF, which is intended for the transport of Charging Data Records (CDRs). The CDF could either be GGSN, P-GW, S-GW, or any other similar products.
By definition, dealing with CDRs only implies that Ga is solely related to offline charging.
The following figure depicts the position of the Ga reference point within the overall 3GPP offline charging architecture.
 
3GPP Offline Charging Architecture
As illustrated in the above figure, the CDF in each network domain, service or subsystem is relevant for the network side of the Ga reference point. Different mappings of the ubiquitous offline charging functions, CDF and CGF, onto physical implementations are possible.
The transport protocol associated to the Ga reference point, providing functions for transfer of CDRs from CDF to CGF, is GTPP.
Each CDF will have an O&M configurable address list of CGFs (Charging Gateways) to which it can send its CDRs. The list will be organized in CGF address priority order. If the primary CGF is not available (for example, out of service), then the CDF will send the CDRs to the secondary CGF and so on.
Each CDR generating function will only send the records to the CGF(s) of the same PLMN, not to CGF(s) located in other PLMNs.
Each CGF in the PLMN will know the other CGFs' network addresses (for example, for redundancy reasons, to be able to recommend another CGF address). This is achieved by O&M configuration facilities that will enable each CGF to have a configurable list of peer CGF addresses.
 
CDR Transport by GTPP
GTPP has been designed to deliver the CDR(s) from the CDF to the CGF(s). This protocol is required if the CGF resides outside the CDFs. It utilizes some aspects of GTPP, which is used for packet data tunneling in the backbone network.
GTPP operates on the Ga interface and does not imply the use of any specific backbone network.
GTPP performs the following functions:
 
•
CDR transfer between the CDF and the CGF
•
Redirection of CDRs to another CGF
•
Advertise to peers about its CDR transfer capability (for example, after a period of service downtime)
•
Prevents duplicate CDRs that might arise during redundancy operations. If so configured, the CDR duplication prevention function may also be carried out by marking potentially duplicated CDR packets, and, delegating the final duplicate deletion task to a CGF or the Billing Domain (instead of handling the possible duplicates solely by GTPP messaging).
 
Path Protocol
GTPP uses path protocol to transport CDRs from CDF to CGF over the Ga interface so as to facilitate charging.
The following path protocols are supported for GTPP:
 
•
UDP as the Path Protocol
Ports for signaling the request messages:
•
The UDP Destination Port may be the server port number 3386 which has been reserved for GTPP. Alternatively, another port can be used as configured by O&M.
•
The UDP Source Port is a locally allocated port number at the sending network element.
Ports for signaling the response messages:
•
The UDP Destination Port can be the value of the Source Port of the corresponding request message.
•
The UDP Source Port can be the value from the Destination Port of the corresponding request message.
•
TCP as the Path Protocol
The TCP Destination Port may be the server port number 3386, which has been reserved for G-PDUs. Alternatively, another port may be used as configured by O&M. Extra implementation-specific destination ports are possible but all CGFs shall support the server port number.
The TCP Source Port is a random port locally assigned at the sending network element.
note_smallImportant: ASR 5K supports IPV4 only as a transport layer IP.
 
GTPP Message Types
GTPP defines a set of messages between two associated nodes. The GTPP messages defined are shown in the following table.
 
GTPP Messages
Message Type value (Decimal)
GTPP Message
1
Echo Request
2
Echo Response
3
Version Not Supported
4
Node Alive Request
5
Node Alive Response
6
Redirection Request
7
Redirection Response
240
Data Record Transfer Request
241
Data Record Transfer Response
Others
Reserved for future use
‌
The messages introduced by GTPP are in boldface letters. The other messages are inherited from GTPP protocol.
The GTPP introduced the following signaling message types as Path Management Messages:
 
•
Node Alive Request
•
Node Alive Response
•
Redirection Request
•
Redirection Response
note_smallImportant: Echo messages and node-alive messages are not supported if the transport layer protocol is TCP.
The following signaling messages are grouped under the category “Record Transmission Messages”:
 
•
Data Record Transfer Request
•
Data Record Transfer Response
The reserved fields in the signaling messages can be filled with ones, and are intended for future use.
GTPP reuses the GTPP Cause values. The message type numbers required for the newly introduced GTPP messages have been derived from the unallocated message type number space specified in the GTPP message table defined in TS 29.060.
The number ranges allocated for GTPP are as follows:
For Information Elements: 117-127 (TV type fields) and 239-254 (for TLV type fields).
The following table provides the information on the TLV and TV Information Element types introduced in this document:
TLV and TV Information Element Types
TLV Information Element Types
254
Address of Recommended Node
253
Requests Responded
252
Data Record Packet
251
Charging Gateway Address (this IE is also used in TS 29.060 [200])
250
Sequence Numbers of Canceled Packets
249
Sequence Numbers of Released Packets
TV Information Element Types
127
Charging ID
126
Packet Transfer Command
‌
 
Usage of GTPP Header in Charging
In GTPP messaging only the signalling plane of GTPP is partly reused. The GTPP header is shown in the following figure.
 
GTPP Header
Bit 5 of octet 1 of the GTPP header is the Protocol Type (PT) flag: it is '0' if the message is GTPP.
The Version bits indicate the GTPP protocol version when the Protocol Type flag is '0'.
Bit 1 of octet 1 is not used in GTPP (except in v0), and it is marked '0' in the GTPP header. It is in use in GTPP v0 and distinguishes the used header-length. In the case of GTPP v0, this bit being marked one (1) indicates the usage of the 6 octets header. If the bit is set to '0' (usually the case) the 20-octet header is used. For all other versions of GTPP, this bit is not used and is set to '0'. However, this does not suggest the use of the 20-octet header, rather a shorter 6-octet header.
The Length indicates the length of payload (number of octets after the GTPP header). The Sequence Number of the packet is part of the GTPP header.
 
Information Elements
The messages contain several Information Elements (IEs). The TLV (Type, Length, Value) or TV (Type, Value) encoding formats will be used for the GTPP IEs. The GTPP messages have the IEs sorted with the Type fields in ascending order. The Length field contains the IE length excluding the Type and Length fields.
Within the Type field the most significant bit will be set to 0 when the TV format is used and set to 1 when the TLV format is used.
 
GTPP Messages
This section provides the detailed information on the GTPP message types.
 
Node Alive Request
The Node Alive Request message may be used to inform that a node in the network has started its service (e.g. after a service break due to software or hardware maintenance or data service interruption after an error condition). A node may send a different Node Address than its own in the Information Element, e.g. informing the "next node in the chain" that the "previous node in the chain" (which is located on the other side of the sender of this message) is now ready for service.
The Node Alive Request message allows a quicker reconnect capability than the Echo Request message based polling can provide, and its usage will have a reduced load effect on the network, particularly when the number of network nodes using GTPP is high. It may also be used to inform when a new network node has become available for service. If the Echo Request message is also used, then the usage of the Node Alive Request message allows the interval of Echo Requests to be longer, thus reducing network load by reducing number of Echo Requests.
note_smallImportant: Node Alive request messages are not supported if the transport layer protocol is TCP.
The Information elements in a Node Alive Request message are shown in the following table:
Node Alive Request Message
Information Element
Presence Requirement
Node Address
Mandatory
Alternative Node Address
Optional
Private Extension
Optional
‌
The Node Address format is the same as for the Charging Gateway Address format described in TS 29.060.
The format definition for the Node Address information element is the same as the format of the source and destination address of the IP packet that transports the GTPP messages. The optional Alternative Node Address IE can be used in the Node Alive Request if the message sender wants to advertise an IP address that is different from the node address format. This way both the IPv4 and IPv6 node address formats can be supported simultaneously in the messaging, regardless of whether IPv4 or IPv6 is used in the underlying transport.
The optional Private Extension IE contains vendor- or operator-specific information.
 
Node Alive Response
The Node Alive Response message, shown in the following table, shall be sent as a response to a received Node Alive Request.
 
Node Alive Response Message
Information Element
Presence Requirement
Private Extension
Optional
‌
The optional Private Extension IE contains vendor- or operator-specific information.
 
Redirection Request
There are two use cases for the Redirection Request message:
 
•
One is to advise that received CDR traffic is to be redirected to another CGF due to the sending CGF node is about to stop service (due to an outage for maintenance or an error condition).
•
The second purpose is to inform a CDF which is currently sending data to this node (e.g. CGF), that the next node in the chain (e.g. a mediator device or Billing Computer) has lost connection to this node (e.g. CGF).
The Information Elements in a Redirection Request Message are listed in the following table. An Address of Recommended Node may be given if, for example, a CGF maintenance outage is handled by first introducing another CGF ready to take incoming CDRs. This way, the network performance can be maintained. The Address of Recommended Node shall only describe an intra-PLMN node containing a CGF, and not a node in any other PLMN.
 
Redirection Request Message
Information Element
Presence Requirement
Cause
Mandatory
Address of Recommended Node
Optional
Alternative Address of Recommended Node
Optional
Private Extension
Optional
‌
Possible Cause values are:
 
•
This node is about to go down
•
Another node is about to go down
•
System failure
•
Receive buffers becoming full
•
Send buffers becoming full
The Address of Recommended Node IE, shown in the following figure, defines the IPv4 or IPv6 format address that the node is identified by in the UMTS network.
 
Address of Recommended Node IE
The format definition for the Address of Recommended Node information element is the same as the format of the source and destination address of the IP packet that transports the GTPP messages. The optional Alternative Address of Recommended Node IE can be used in the Node Alive Request if the message sender wants to advertise an IP address that is different from the node address format. This way both the IPv4 and IPv6 node address formats can be supported simultaneously in the messaging, regardless of whether IPv4 or IPv6 is used in the underlying transport.
The optional Private Extension contains vendor- or operator- specific information.
 
Redirection Response
A Redirection Response message shall be sent as a response of a received Redirection Request.
The information elements of this message are listed in the following table.
Redirection Response Message
Information Element
Presence Requirement
Cause
Mandatory
Private Extension
Optional
‌
Possible Cause values are:
 
•
Request Accepted
•
No resources available
•
Service not supported
•
System failure
•
Mandatory IE incorrect
•
Mandatory IE missing
•
Optional IE incorrect
•
Invalid message format
•
Version not supported
The optional Private Extension contains vendor- or operator-specific information.
 
Data Record Transfer Request
This message is used to transmit the CDR(s) to the CGF.
The CDRs are placed in the Data Record Packet information element.
 
Information Elements in Data Record Transfer Request
The IEs in Data Record Transfer Request message are specified in the following table.
 
Data Record Transfer Request Message
Information Element
Presence Requirement
Packet Transfer Command
Mandatory
Data Record Packet
Conditional
Sequence Numbers of Released Packets
Conditional
Sequence Numbers of Canceled Packets
Conditional
Private Extension
Optional
‌
 
Packet Transfer Command IE
The value of the Packet Transfer Command in its Information Element tells the nature of the message:
 
•
1 = 'Send Data Record Packet'
•
2 = 'Send possibly duplicated Data Record Packet'
•
3 = 'Cancel Data Record Packet'
•
4 = 'Release Data Record Packet'
The following describes the usage of each Packet Transfer Command. The first command is for normal CDR transfer while the other values are only used as part of the redundancy mechanism.The following describes the usage of each Packet Transfer Command. The first command is for normal CDR transfer while the other values are only used as part of the redundancy mechanism.
Send Data Record Packet: This is the usual command used for sending CDRs under normal conditions when no error recovery is needed or the redirection mechanism is not involved. The other three commands are being used only in error recovery cases. Out of the three conditional IEs, only the "Data Record Packet" is present in this message.
Send possibly duplicated Data Record Packet: When the CDR packet is redirected to a secondary CGF (by a CDF) because the currently used CGF is not working or the CDR transfer is not working properly, or if there is an error in the link between the CDF and the CGF, then this Packet Transfer Command is used instead of the normal 'Send Data Record Packet'. Of the conditional IEs, the "Data Record Packet" is present in the message, when sending the message to a CGF acting as temporary storage, when the original primary CGF could not be contacted. This Packet Transfer Command is used also when sending "empty" test packets with older (but not yet acknowledged) sequence numbers after a peer node or link recovery, to check if the CGF had received some Data Record Packets (whose acknowledgement did not come to the Data Record Packet sending node) before the link to the recipient node became inoperable.
Cancel Data Record Packet: Of the conditional IEs, the "Sequence Numbers of Canceled Packets" is present in the message.
Release Data Record Packet: Of the conditional IEs, the "Sequence Numbers of Released Packets" is present in the message.
After the CGF has received the Packet Transfer Command 'Release Data Record Packet' with the Sequence Number(s) for earlier sent 'Send possibly duplicated Data Record Packet' command(s), it can consider itself authorized to send the Data Record Packets previously marked as possibly duplicated towards the BD as normal (not duplicated) CDRs.
 
Data Record Packet IE
The Data Record Packet element, which is present conditionally if the Packet Transfer Command is 'Send Data Record Packet' or 'Send possibly duplicated Data Record Packet', may contain one or more CDRs. If an "empty packet" is to be sent, then the Data Record Packet IE contains only the Type (with value 252 in decimal) and the Length (with value 0) fields.
There are two fields identifying the CDR format: Data Record Format and Data Record Format Version.
The format of the CDRs is ASN.1 or some other format, as identified by the value of Data Record Format. The Data Record Format Version identifies the TS release and version numbers that were used for the CDR encoding.
 
Sequence Numbers of Released Packets IE
The Sequence Numbers of Released Packets is present if the Packet Transfer Command is 'Release Data Record Packet'. The format of the Information Element is described in the following figure:
 
Sequence Numbers of Released Packets IE
 
Sequence Numbers of Canceled Packets IE
The following figure shows the sequence numbers of Canceled Packets IE that contains the IE Type, Length and the Sequence Number(s) (each 2 octets) of the canceled Data Record Transfer Request(s). It is present if the Packet Transfer Command is "Cancel Data Record Packet".
 
Sequence Numbers of Canceled Packets IE
 
Private Extension IE
The optional Private Extension contains vendor- or operator- specific information.
 
Data Record Transfer Response
The message shall be sent as a response to a received Data Record Transfer Request. Also, several Data Record Transfer Requests can be responded by a single Data Record Transfer Response.
The Cause (whatever the value may be) applies for all those Data Record Transfer Requests, responded by that particular Data Record Transfer Response.
Possible Cause values are:
 
•
Request Accepted
•
No resources available
•
Service not supported
•
System failure
•
Mandatory IE incorrect
•
Mandatory IE missing
•
Optional IE incorrect
•
Invalid message format
•
Version not supported
•
Request not fulfilled
•
CDR decoding error
•
Request already fulfilled
•
Request related to possibly duplicated packet already fulfilled
•
Sequence numbers of released/canceled packets IE incorrect
The cause value "CDR decoding error" is optional, primarily intended to inform the CDF that the receiving node cannot decode the CDR. Thus, special features in the receiving node that are based on information within the CDR, would not be operable. This message alerts the operator of a remote generating node of incompatible CDR encoding. It is optional and no action or response is required.
The Requests Responded IE contains the IE Type, Length and the Sequence Numbers (each 2 octets) of the Data Record Transfer Requests.
The optional Private Extension contains vendor- or operator- specific information. Depending on the Cause value severity and general occurrence frequency, the node that sent the corresponding Data Record Transfer Request, may start to direct its CDRs to another CGF.
 
Handling Error Response Cause
By default, on getting an error response, the request is retried to the same CGF server until max-retries is reached. Then the server is marked as NOT ACTIVE and the request is retried to the secondary server. This behavior is seen for the below response causes.
 
•
Mandatory IE incorrect
•
Mandatory IE missing
•
Optional IE incorrect
•
Invalid message format
On getting the following error response causes, the request will NOT retried and the server will be marked as NOT ACTIVE immediately.
 
•
No resources available
•
Service not supported
•
System failure
No special action is taken on getting "CDR Decoding error" response cause and the behavior is similar to getting a "Request Accepted" cause.
On getting "Version not supported" cause, the request is resent with the version supported by the CGF server (by default, GTPP v2 is supported).
 
GTPP Configuration
Cisco Systems’ GGSN/P-GW/S-GW supports both GTPP- and RADIUS-based accounting. The accounting protocol is configured on a per-APN basis.
When the GPRS Tunneling Protocol Prime (GTPP) protocol is used, accounting messages are sent to the Charging Gateways (CGs) over the Ga interface. The Ga interface and GTPP functionality are typically configured within the system's source context. As specified by the standards, a CDR is not generated when a session starts. CDRs are generated according to the interim triggers configured using the charging characteristics configured for the GGSN, and a CDR is generated when the session ends. For interim accounting, STOP/START pairs are sent based on configured triggers.
GTPP version 2 is always used. However, if version 2 is not supported by the Charging Gateway Function (CGF), the system reverts to using GTPP version 1. All subsequent CDRs are always fully-qualified partial CDRs. GTPP version 0 is not supported.
GTPP is configured at the routing context level. Some of the configurables associated with GTPP are Attributes, Charging Agent, Deadtime, etc. The GTPP configuration commands vary according to the services configured, for example, the commands used for GGSN might differ from what is configured for P-GW. For more information on the configuration commands, refer to the Cisco ASR 5000 Series Command Line Interface Reference.
 
Charging Characteristics
Whether or not the GGSN accepts charging characteristics from the SGSN, the accounting protocol can be configured on a per-APN basis based on whether the subscriber is visiting, roaming or, home.
By default, the GGSN always accepts the charging characteristics from the SGSN. They will be provided by the SGSN for GTPv1 requests for primary PDP contexts. If they are not provided for secondary PDP contexts, the GGSN re-uses those from the primary. The charging characteristics field is optional. If not provided by SGSN the GGSN selects the locally configured values. Also, there is a provision to override the values from RADIUS as indicated in the following table.
 
CLI command configured on GGSN
Sent by SGSN
Sent by AAA
CC used
no cc-sgsn
no cc
no cc
Default
cc
Default
cc
no cc
SGSN
cc
SGSN
cc-sgsn use-ggsn
no cc
no cc
GGSN
cc
GGSN
cc
no cc
GGSN
cc
GGSN
cc-sgsn radius-returned
no cc
no cc
Default
cc
AAA
cc
no cc
SGSN
cc
AAA
cc-sgsn radius-returned use-ggsn
no cc
no cc
GGSN
cc
AAA
cc
no cc
GGSN
cc
AAA
‌
If the system is configured to reject the charging characteristics from the SGSN, the GGSN can be configured with its own that can be applied based on the subscriber type (visiting, roaming, or home) at the APN level. The charging characteristics consists of a string of 16 bits designated as profile index and behavior settings. The GGSN supports up to 16 profile indexes numbered 0 through 15 whereas P-GW/S-GW supports up to a maximum of 256 charging profiles.
The profile indexes specify the criteria for closing accounting records based on specific criteria.
When a bearer is activated, an appropriate charging profile will be selected based on the following sources of input:
•
Downloaded AAA attribute (ONLY in P-GW)
•
MME/HSS via charging characteristics IE
•
Local defaults
Following is the order of precedence when charging profile value is received from multiple sources.
•
Profile index in the override rule on the APN
•
Profile index in the override rule on the gateway
•
Profile index from AAA in case of P-GW
•
Profile index from non-override rule on the APN
•
Profile index from non-override rule on the gateway
For more information on the commands that configure additional GTPP accounting properties, refer to the Cisco ASR 5000 Series Command Line Interface Reference.
 
GTPP Accounting Interface in ECS
Enhanced Charging Service (ECS) supports different accounting and charging interfaces for prepaid and postpaid charging and record generation.
GTPP accounting in ECS allows the collection of counters for different types of data traffic and including that data in a G-CDR that is sent to the CGF.
Standard G-CDRs do not have an attribute which defines traffic counters depending upon the traffic type but they do have a field named Record Extensions where all vendor specific information can be included. ECS includes the counters for different types of data traffic in this field when sending a G-CDR.
 
Charging Record Generation
ECS provides for the generation of charging data files, which can be periodically retrieved from the system and used as input to a billing system for post-processing.
The results of traffic analyzer are used to generate session usage data. The generated usage data are in a standard format, so that the impact on the existing billing system is minimal and at the same time, these records contain all the information required for billing based on the content.
The accounting records also contain the information to identify the user, with Dynamic address assignment and information to obtain the URL for HTTP content request or a file-name or path from FTP request, the type of service from the first packet of the connection, and transaction termination information so that the billing system can decide transaction success or failure.
Charging records support details of the termination such as which end initiated the termination, termination type e.g. RST, FIN, etc. and in case of HTTP 1.1, whether or not the connection is still open. ECS supports pipelining of up to 15 HTTP requests on the same TCP connection. The billing system, based on this information, decides upon the success or failure of the connection and charge or refund accordingly.
To cover the requirements of standard solutions and at the same time, provide flexible and detailed information on service usage, ECS provides the following types of usage records:
 
•
Standard GGSN Call Detail Records (G-CDRs)
•
Enhanced GGSN Call Detail Records (eG-CDRs)
The ASR 5000 Series Multimedia Core Platform supports multiple fields for use in G-CDRs and eG-CDRs. All G-CDRs and eG-CDRs are encoded using the ASN.1 format and are sent to the CGF using the GTPP.
note_smallImportant: The behavior for several of the fields supported in CDRs can be modified. For more information, refer to the Cisco ASR 5000 Series Command Line Interface Reference.
 
Standard GGSN Call Detail Records (G-CDRs)
G-CDRs are generated according to 3GPP TS 32.251 V6.6.0. Currently ECS supports generation of CDRs using AAAMgrs only.
 
G-CDR Format
The G-CDRs can be in ASN.1 Format.
 
Enhanced GGSN Call Detail Records (eG-CDRs)
The ECS also supports enhanced G-CDRs, which is an enhanced format of standard G-CDRs to provide greater portability of charging information. eG-CDRs are compliant with 3GPP TS 32.298 v6.5.0 for Rel. 6 based dictionaries, and with 3GPP TS 32.298 v7.4.0 for Rel. 7 based dictionaries.
By default, the G-CDR does not support the traffic and vendor specific records. To support a traffic and vendor specific record, the ECS must be configured to generate eG-CDRs. eG-CDRs are useful to implement Time Based Charging (TBC) and Flow Based bearer Charging (FBC) to ECS.
eG-CDR supports customer specific formats configured in Ga context in a GGSN service with standard or custom specific GTPP dictionaries.
 
eG-CDR Format
The eG-CDRs can be in ASN.1 Format.
For more information on G-CDR and eG-CDR attributes and definitions, refer to the G-CDR and Enhanced G-CDR Field Descriptions chapter in this reference guide.
 
PDN Gateway Call Detail Records (PGW-CDRs)
PGW-CDRs are generated according to 3GPP TS 32.298 V8.5.0.
 
PGW-CDR Format
The PGW-CDRs can be in ASN.1 Format.
 
Serving Gateway Call Detail Records (SGW-CDRs)
SGW-CDRs are generated according to 3GPP TS 32.298 V8.5.0.
 
SGW-CDR Format
The SGW-CDRs can be in ASN.1 Format.
 
Sample GTPP Configuration
This section provides an example of the sample GTPP configuration applied to various products.
 
Sample Configuration for GGSN/PGW
This section provides an example of the sample GTPP configuration for GGSN and PGW.
1.
Configure the GTPP group and accounting context configuration in APN level and also specify the accounting-mode.
configure
  context source
     apn apnname1.com
     accounting-mode gtpp
     gtpp group group1 accounting-context billing
     end
2.
Configure the GTPP group related parameters like GTPP server parameters, GTPP dictionary, and optionally CGF to support GTPP accounting:
configure
  context source
     gtpp group group1
     gtpp charging-agent address 1.2.3.4 port 3386
     gtpp server 1.3.5.6 max msgs priority 1
     gtpp dictionary dict1
     gtpp max-cdr 255 wait-time 10
     gtpp transport-layer udp
     end
note_smallImportant: For GGSN, accounting context can also be configured in GGSN service. In this case more priority will be given to the APN level configuration. In APN level, if no accounting context is configured then accounting context configured in GGSN service shall be considered.
configure
  context source
     ggsn-service ggsn1
     accounting context billing
     end
 
Sample Configuration for SGW
This section provides an example of the sample GTPP configuration for SGW.
1.
In subscriber level configure GTPP in the accounting-mode.
configure
  context dest1
     subscriber default
     accounting-mode gtpp
     end
2.
Configure accounting policy in context level. This is required only for time/tariff/volume threshold configuration.
configure
  context dest1
     policy accounting lte
     cc profile 1 interval 60
     cc profile 1 volume total 100000
     cc profile 1 tariff time 1 0 0 time 2 2 2 time 3 4 4 time 4 5 5
     cc profile 1 buckets 3
     cc profile 1 serving-nodes 4
     end
3.
Associate the accounting policy with the SGW service.
configure
  context source
     sgw-service sgw1
     associate accounting-policy lte
     end
4.
Configure the accounting context and GTPP group in SGW service level. If accounting context is not configured in SGW service the source context and "default" GTPP group will be selected.
configure
  context source
     sgw-service sgw1
     accounting context dest1 gtpp group sgw
     end
5.
Configure the GTPP group related parameters.
configure
  context source
     gtpp group group1
     gtpp charging-agent address 1.2.3.4 port 3386
     gtpp server 1.3.5.6 max msgs priority 1
     gtpp dictionary dict1
     gtpp max-cdr 255 wait-time 10
     gtpp transport-layer udp
     end
 
 
Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883